fabric.mod.json: minecraft version constraint and missing fabric-api dependency

The minecraft dependency still requires >=1.21.11, but since all code now targets 26.1 APIs (renamed classes, new method signatures, new types like TagValueInput/ContainerInput/InsideBlockEffectApplier), the mod will crash on any version below 26.1. This should be updated — you could use the template variable that's already wired up in build.gradle.kts:

"minecraft": ">=${minecraft}"

Also, the fabric-api line was removed from depends, but the mod still heavily imports from net.fabricmc.fabric.api.* (event bus, networking, lifecycle events, player interaction callbacks, command registration). Without it in depends, users who don't have Fabric API installed will get an opaque NoClassDefFoundError instead of a clear missing-dependency message from the loader. Consider restoring it:

"fabric-api": ">=${fabricApi}"

DatabaseManager.kt: playernameKeys BiMap crashes on player name change

playernameKeys is a HashBiMap<String, Int>, which enforces value uniqueness. In insertOrUpdatePlayer (line 485), when a player who previously joined changes their Minecraft username and reconnects, the old name→id mapping still exists in the cache. BiMap.put() (which [] delegates to) throws IllegalArgumentException when the value is already bound to a different key.

Example: player joins as "Alice" → playernameKeys["Alice"] = 3. Player renames to "Bob" and rejoins → playernameKeys["Bob"] = 3 throws because value 3 is still mapped from "Alice".

Fix: use forcePut() which removes any existing entry for the value before inserting. This applies to all three write sites:

// line 143 (setupCache)
cache.playernameKeys.forcePut(it.playerName, it.id.value)

// line 485 (insertOrUpdatePlayer, existing player branch)
cache.playernameKeys.forcePut(name, player.id.value)

// line 492 (insertOrUpdatePlayer, new player branch)
cache.playernameKeys.forcePut(name, entity.id.value)

DatabaseManager.kt: !! on cache lookups in getActionsFromQuery can crash entire queries

In getActionsFromQuery (lines 237-243), several inverse cache lookups use !!. If any action row references an ID not present in the in-memory cache, the NullPointerException aborts the entire query and all results are lost.

The playerNameCache lookup on line 243 is the most likely to hit this in practice — it's a new cache, and there could be edge cases where playerKeys has an entry but playernameKeys doesn't (e.g., a player record with a null or empty name in the DB from an older schema).

Consider a safer approach, at minimum for the sourceProfile construction:

type.sourceProfile = action.getOrNull(Tables.Actions.sourcePlayer)?.let {
    val uuid = playerCache[it.value]
    val name = playerNameCache[it.value]
    if (uuid != null && name != null) NameAndId(uuid, name) else null
}